A database is a collection of related files or data that is created and managed by a database management system (DBMS) in a predefined format. For example, the DBMS can be arranged in tables that contain rows and columns. Queries can be constructed in accordance with a query language (e.g., structured query language (SQL)) in order to access content of a table in the database. Likewise, data can be input (e.g., imported) into the table via an external source. Conventionally, the DBMS can manage any form of data including text, images, sound and video. In accordance therewith, database and file structures are determined by a software application.
The DBMS can employ predefined simple data types that can refer to a category of variables that is determined by the kind of data stored in it. For example, integer, floating point, string, date, binary, boolean, character, short, and long are common simple data types. Recently, efforts have been directed to the utilization of a user defined type (UDT) to increase DBMS storage flexibility and management. More particularly, the functionality of a UDT affords developers and users the flexibility to create a UDT (e.g., via a declarative language), which is compatible with a particular database application.
UDTs enable the modeling and manipulation of complex types within a storage environment (e.g., DBMS). UDTs further provide for concepts such as inheritance, containment, and multi-valued embeddings. A UDT can comprise a series of fragments of different types (e.g., integer, floating point, string, date, binary, boolean, character, short, long, . . . ). For example, a UDT fragment can be a portion of a UDT that has associated metadata (e.g., for a UDT related to a person, one fragment can hold the person's name, another can relate to the person's address, . . . ). The size of a UDT fragment can vary depending on its type and/or an associated payload. UDTs can be stored in data page(s) and/or transferred as part of data packet(s). Due to their varying sizes, UDTs and/or UDT fragments can be split between disparate data pages when stored (or data packets while transferred). UDTs and/or UDT fragments can be split, for example, if there is not enough free space within a data page to store the UDT and/or UDT fragment. For instance, a 10,000 byte UDT cannot be stored in one 8192 byte data page; thus, such a UDT is split between data pages. Additionally, depending upon a location of the split of the UDT, portions of a UDT fragment may be separated between disparate data pages. Splitting of a UDT fragment can cause a simple data type to be split; by way of example, a four byte integer can be stored such that a first byte is stored in a first data page and the remaining three bytes are stored in one or more other data pages.
Conventionally, before a consistency check can be performed on a fragment, the entire fragment has to be materialized in memory. Thus, in the case of a fragment split between two disparate data pages or data packets, both sections of the fragment would have to be copied to another area of memory for further processing. Thus, currently employed techniques are expensive in terms of memory and processing resources. Additionally, this expense increases as the fragment size (and hence an associated number of data pages or data packets) increases.